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community. It does not specify an Internet standard of any kind. 
Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 
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based on IETF review for such things as security, congestion control 
or inappropriate interaction with deployed protocols. The RFC Editor 
has chosen to publish this document at its discretion. Readers of 
this document should exercise caution in evaluating its value for 
implementation and deployment. 


Abstract 


The Netnews Administration System (NAS) is a framework to simplify 
the administration and usage of network news (also known as Netnews) 
on the Internet. Data for the administration of newsgroups and 
hierarchies are kept in a distributed hierarchical database and are 
available through a client-server protocol. 


The database is accessible by news servers, news administrators, and 
news readers. News servers can update their configuration 
automatically; administrators are able to get the data manually. 
News reader programs are able to get certain information from an NAS 
server, automatically or at a user's discretion, which provides 
detailed information about groups and hierarchies to the user. 
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NAS is usable in coexistence with the current, established process of 
control messages; an unwanted interference is impossible. 
Furthermore, NAS is able to reflect the somewhat chaotic structure of 
Usenet in a hierarchical database. NAS can be used without 
modification of existing news relay, news server, or news reader 
software; however, some tasks will be better accomplished with NAS- 
compliant software. 
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1. Introduction 


An increasing number of newsgroups, hierarchies, and articles has 
made the administration of news servers a complex and time-consuming 
task. The tools for the administration have remained unchanged for 
ten years and are no longer appropriate. Many hierarchies are 
inconsistent; many new newsgroups are not created or only with a 
large delay; removed groups keep lurking in the configuration files 
for a long period of time. There is no administration tool that 
utilizes the power of the Internet, and it is not possible to check 
the consistency of the news server at a given point of time. 


Users find it difficult to get an overview of the newsgroups, the 

charter of a particular one, which language is preferred, or whether 
a group is moderated. Renaming, the status change from moderated to 
unmoderated or vice versa, and the splitting of a group into several 


others are dynamic processes. These processes are in common use, but 
it takes a long time until every news server is aware of these 
changes. 


An increasing number of faked control messages has appeared in the 
last few years. Purposely or accidentally, control messages were 
sent to foreign news servers to create or remove a certain group, 
although this was not approved according to the rules of the 
hierarchy in question. Due to this fact, automatic creation and 
removal are disabled on many news servers, and several dead groups 
have not been deleted. It is very difficult for users to determine 
the current status of a group, and in some cases they simply cannot 
tell that the group they are posting to is not an active group but a 
dead or invalid one. 


It is the design goal of Netnews Administration System (NAS) to 
provide an out-of-band system that helps to maintain, propagate, and 
deliver the required information. There will not be any interference 
with current protocols and standards. It is not intended to make use 
of control messages or some special Network News Transfer Protocol 
(NNTP) commands. The advantage of NAS is that it provides more 
information in a more structured format than that of control 
messages. Not only news server administrators but also Usenet users 
can get more detailed information about newsgroups and hierarchies. 


Due to the fact that a client connects to a server and the server 
asks for authentication, this is a more reasonable procedure for 
transmitting information than that for control messages. 
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Furthermore, it is possible to check for changes on a regular basis 
at customized intervals to keep local data up-to-date. 


2. Overview 


NAS is based on a database that contains information about certain 
groups and hierarchies. This database is structured in a 
hierarchical manner and distributed to various servers, and it is 
able to receive queries at any time. The service is comparable to 
directory services like DNS, Lightweight Directory Access Protocol 
(LDAP), or Network Information Service (NIS). The NAS protocol is 
inspired by protocols like NNTP and SMTP. The port 991 is reserved 
for NAS and registered by the Internet Assigned Numbers Authority 
(IANA) [IANA-PN]. 


The organizational structure of NAS is hierarchical; this means that 
a NAS root server collects data from the sub-servers that are 
authoritative for certain hierarchies. The root server signs the 
data and distributes it authoritatively. Replication of database 
entries is possible. The hierarchical structure can consist of 
multiple levels. Usage of the database is possible for news servers, 
news readers, and special client programs. The communication is 
based on TCP and UDP. 


Taking the real world into account, there might be some policy 
problems with a single root server. But it is possible to establish 
a structure like that of the current Usenet system, where some 
hierarchies have a good administration with a well-defined system of 
rules, and where some are not well maintained. The goal is to get as 
much information as possible under one hat, but there can be no 
"official" force to achieve this. 


During the startup phase, it is quite likely that there will be a 
root server, handling just hierarchies with strict rules and accepted 
authorities (e.g., BIG8, de.*, us.*, bln.*, fr.*, it.*). 


However, it is also imaginable to have some NAS servers providing 
data on, for example, alt.!binaries, some providing data on alt.*, 
and even some providing alt.* following special policies or sets of 
rules. 


An administrator using NAS will have the choice to use just one root 
server (and all its data) or to use another NAS server for special 
hierarchies. 
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Figure 1 


NAS contains information about newsgroups and complete hierarchies. 
Furthermore, it contains information about the hierarchies’ 
inheritable entries and default values for a single newsgroup. 


3. Protocol Level 


It is expected that the real-life use of NAS will change the 
requirements for the Netnews Administration System. On the one hand, 
the protocol has to be extensible and flexible in order to implement 
improvements; on the other hand, it must ensure compatibility between 
different versions. A simultaneous migration of all sites using NAS 
to a new protocol version is not likely to happen. To solve this 
problem, NAS has a protocol level. This protocol level describes the 
current functionality. The protocol level, being a number between 1 
and 32767, is negotiated at connection setup. Enhancements and 
modifications must use a different protocol level than that of their 
predecessors. (Usually the protocol level is incremented by 1 with 
every new version of the protocol specification.) Every current or 
future implementation MUST be compatible with protocol level 1 in 
order to fall back to this level if communication on a higher level 
fails. 


An implementation of higher protocol levels should be able to emulate 
the behavior of lower levels, even if this implies a loss of 
features. The negotiation of the protocol level between client and 
server is described in the specification of the command VERS. If 
there is no agreement on the protocol level, only commands of the 


Grau, et al. Experimental [Page 5] 


REC 4707 Netnews Administration System (NAS) October 2006 


protocol level 1 MUST be used. Documents enhancing or modifying the 
NAS standard MUST specify on which level these changes take place and 
how the behavior should be in other protocol levels. 


This document describes protocol level 1. 
4. Description of Functions 


In order to use an NAS server, a connection must be opened by the 
client. The NAS server can be located in the same domain or 
somewhere else on the Internet. 


The NAS system is hierarchical. The idea is to have an NAS root 
server like the DNS root servers. The root server distributes the 
data collected from client NAS servers that are authoritative servers 
for their hierarchy. The maintenance of the authoritative data is 
possible on any system. The root server collects the data and makes 
them available to other servers, which can in turn distribute these 
data to other servers. The administrator has the opportunity to make 
use of either all data or only parts of the database. NAS servers 
can ask multiple NAS servers for data. An attached time stamp makes 
it possible to distinguish between new and old data and to avoid 
loops in the propagation. 


To describe the NAS in greater detail, it is necessary to emphasize 
the hierarchical design of the NAS system. The following figure 
shows the propagation of data along the server hierarchy. 


Authoritative data for a newsgroup or a hierarchy are collected and 
written into a database. These data are available through a local 
NAS server and are collected from this authoritative server by 
upstream NAS servers. 


There may also be NAS servers that are not authoritative servers; 
these servers merely provide the information they collect from other 
NAS servers to clients such as news servers, administration programs, 
and news readers. 
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Requests to an NAS server originating at a client (as well as at 
another server) are accomplished in several steps: establishing a 
connection, authentication (optional), negotiating a protocol level 
(optional), queries on the database, and termination. 


Definitions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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6. Specification of the NAS Protocol (TCP) 
6.1. Responses 
6.1.1. Overview 


An answer starts with a response code (a three-digit number), 
optionally followed by white space and a textual message. Then the 
actual text/data follows. Text is sent as a series of successive 
lines of textual matter, each terminated with CRLF. A single line 
containing only a single period (’.’) is sent to indicate the end of 
the text (i.e., the server will send a CRLF at the end of the last 
line of text, a period, and another CRLF). 


Answer = response-code [answertext] CRLF 
text CRLF 
"CREF 


If the original text contains a period as the first character of the 
text line, that first period is doubled. Therefore, the client must 
examine the first character of each line received and, for those 
beginning with a period, determine either that this is the end of the 
text or that it should collapse the doubled period to a single one. 


Example 


<-- INFO 

--> 101 Information follows 
Server: nas.example.org (192.0.2.100) 
Uptime: 2 weeks, 3 days, 5 hours, 9 minutes 
Software: NAS 1.0 
Client: client.example.org (192.0.2.123) 
Connection: 9 minutes 
Highest protocol level supported: 1 
Requested protocol level: 1 
Protocol level used: 1 


6.1.2. Response Code Values, Structure, and Meaning 


The first digit of the response code indicates the message type 
(i.e., information, success, warning, error, or data): 


1xx Information 

2xx Request successful 

3xx Request successful, data follow 

4xx Request accepted, but no operation possible 


Grau, et al. Experimental [Page 8] 


REC 4707 Netnews Administration System (NAS) October 2006 


5xx Request is wrong (syntax error), is not implemented, or leads to 
an internal error 
6xx Request successful, data follow until end mark 


The second digit specifies the message category: 


x0x Connection-related stuff 

xlx Queries, answers, or data 

x2x Server-server communication 
x3x Authentication, authorization 
x8x Non-standard extensions 

x9x Debugging output 


The actual response code for a specific command is listed in the 
description of the commands. Answers of the type 1xx, 2xx, 4xx, and 
5xx can have a text after the numerical code. 3xx answers contain 
one or more parameters with data; the exact format is explained in 
the description of the commands. 


An answer to an incorrect request may be longer than one line. 
6.2. Connection Setup 


NAS typically uses port 991, which is reserved by IANA [IANA-PN]. If 
a connection is set up by the client, the server answers immediately 
(without a request) with the greeting message, which will start with 
code 200: 


--> 200 Welcome! 
nas.example.org ready 


If a connection is refused because the client has no permission to 
access the server, the answer code is 434. That decision can be made 
on connection startup based on the client’s IP address. When the 
server is currently out of service, the answer code is 404. 


Examples: 


--> 434 You have no permission to retrieve data. Good bye. 


--> 404 Maintenance time 


After sending a 404 or 434 message, the connection will be closed. 
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6.3. Commands 
6.3.1. Structure 


A command consists of a command word, sometimes followed by a 
parameter. Parameters are separated from the command word by white 
space. 


Commands used in the NAS protocol are not case sensitive. A command 
word or parameter may be uppercase, lowercase, or any mixture of 
upper- and lowercase. 


The length of a command line is not limited. If the need to limit 
the length of command lines in real-life implementations arises, 
answer code 513 (line too long) should be returned. 


The protocol level described in this document uses command words with 
a length of exactly four characters each. 


In examples, octets sent to the NAS server are preceded by "<-- " and 
those sent by the NAS server by "--> ". The indicator is omitted if 
the direction of the dialog does not change. 

6.3.2. Overview 
The commands described below are defined using the Augmented Backus- 
Naur Form (ABNF) defined in [REC4234]. The definitions for ’ALPHA’, 
'CRLF’, ’DIGIT’, 'WSP” and ’VCHAR’ are taken from appendix B of 
[RFC4234] and not repeated here. 


The following ABNF definitions constitute the set of NAS commands 
that can be sent from the client to an NAS server. 


6.3.3. Detailed Description 


Some overall definitions follow: 


text = $d1-9 / ; all octets except 

%d11-12 / ; US-ASCIT NUL, CR and LF 

%d14-255 
answertext = WSP *( ALPHA / DIGIT / "+" / "-" / "y" / "_" / 

wow / nm / "en / wow / "on / wo / SP ) 
utc-time = 14DIGIT ; the date and time of the server in UTC 
; YYYYMMDDhhmmss 

response-code = 3DIGIT ; three digit number 


Grau, et al. Experimental [Page 10] 


REC 4707 


Netnews Administration System 


(NAS) October 2006 


Newsgroup names and hierarchy names are defined according to the 


following ABNF 
as a newsgroup 


name bln.announce.fub), 


name 
component 
encoded-word 


plain-component 


definitions. 
name (e.g., 


plain-component 
plain-component 
1*( lowercase / 

"." / "u / 
component-start 


Since a hierarchy name can be the same 
hierarchy bln.announce.fub.* and newsgroup 
there is no difference between the two. 


*("." component) 
/ encoded-word 
DIGIT / 
" / " / no / 


*component-rest 


/ 


" >" ) 


Ged esol, 


Grau, 


component-start lowercase / DIGIT 


lowercase = %x61-7A ; letter a-z lowercase 
component-rest = component-start / "+" / "=" / "_" 


NOTE: This definition of newsgroup name is in reference to "News 
Article Format and Transmission" [SON1036]. When the document "News 
Article Format" [USEFOR] is established as an RFC, its definitions 
should be integrated into a higher protocol level of NAS. 


HELP 
Description 


If called 
it will display a complete list of commands. 


This command prints a short help text on a given command. 
without parameters, 


help-cmd = "HELP" [WSP commandname] CRLF 
commandname = "DATA" / "DATE" / "GETP" / "GETA" / 
"HELP" / "HIER" / "INFO" vA "LIST" / 
"LSTR" / "QUIT" / "VERS" 
Possible answers 
100: Command overview, command description 
410: Indicates that the server is not giving any information 


help-answer = "410" [answertext] CRLF 
text CRLF 
To VERE 
help-answer =/ "100" [answertext] CRLF 
text CRLF 
MA CREE 
Examples 
<-- HELP 
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--> 100 NAS server nas.example.org - Version 1.0 


Supported commands: 

DATA - data for a newsgroup 

DATE - show time of server in UTC 

GETP - get package 

GETA - get data from an authoritative server 
HELP - show this help 

HIER - data for a hierarchy 


INFO - show info on current connection 

LIST - list newsgroups or hierarchies 

LSTR - recursive list newsgroups or hierarchies 
QUIT - close the connection 

VERS - show or set current protocol level 


Contact address nas@example.org 


<-- HELP LIST 

--> 100 LIST 
LIST - list newsgroups or hierarchies 
Syntax: LIST hierarchy 
Get a list of newsgroups and sub-hierarchies 
directly under the parameter hierarchy 


<-- HELP NOOP 
--> 410 
unknown command "NOOP" 
6.3.3.2. INFO 


Description 


Prints information about the current connection, the server, and the 
client. 


info-cmd = "INFO" CRLF 
Possible answers 


101: Normal answer; prints some information about client 
and server 


400: Indicates that the server is not giving any information 
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info-answer = "400" [answertext] CRLF 
text CRLF 
me CREE 

info-answer =/ "101" [answertext] CRLF 
text CRLF 
CREB 

Examples 

<-- INFO 


--> 101 Information follows 
Server: nas.example.org (192.0.2.100) 
Uptime: 2 weeks, 3 days, 5 hours, 9 minutes 
Software: NAS 1.0 
Client: client.example.org (192.0.2.123) 
Connection: 9 minutes 
Highest protocol level supported: 1 
Requested protocol level: 1 
Protocol level used: 1 


End 
<-- INFO 
--> 400 

No information available. 

6.3.3.3. ‚DATE 

Description 
Prints the current time of the server in UTC (Universal Coordinated 
Time) in the format YYYYMMDDhhmmss, followed by an optional comment. 
The DATE command is only for informational use and to check the 
server time. For regular transmission of time over the network, the 
Network Time Protocol (NTP) [RFC1305] should be used. 
date-cmd = "DATE" CRLF 


Possible answers 


300: Print the UTC time in specified format; see below 
511: Error; print an error message 


date-answer = "511" [answertext] CRLF 
text CRLF 
he CREF 
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date-answer =/ "300" [answertext] CRLF 
utc-time [answertext] CRLF 
me) (CREE 

Examples 

<-- DATE 

--> 300 


19990427135230 UTC 


<-- DATE 
--> 511 
Time is unknown 


6.3.3.4. VERS 
Description 


The VERS command is used to determine the protocol level to use 
between client and server. The parameter is a protocol level that 
the client supports and wants to use. The server will respond with 
the highest level accepted. This version number MUST not be higher 
than that requested by the client. Client and server MUST only use 
commands from the level that the server has confirmed. It is 
possible, but seldom necessary, to change the protocol level during a 
session by client request (VERS [protocol level]). When no option is 
given, the current protocol level will be printed. When no protocol 
level is negotiated, the protocol level 1 will be used. Commands of 
a higher level are not allowed without successful negotiation. The 
protocol level can be followed by an optional comment. 


vers-cmd = "VERS" [WSP level] CRLF 

level = 1*5DIGIT ; the valid range is 1 - 32767 
Possible answers 

202: Returns current protocol level 

302: Requested level accepted 


402: Requested level too high; falling back to lower level 
510: Syntax error 


vers-answer = "202" [answertext] CRLF 
level [answertext] CRLF 
MS ¿CREE 
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vers-answer =/ "302" [answertext] CRLF 
level [answertext] WSP level CRLF 
Lor “CREF 

vers-answer =/ "402" [answertext] CRLF 
level [answertext] WSP level CRLF 
Du “CRB: 

vers-answer =/ "510" [answertext] CRLF 
level [answertext] CRLF 
TILT- CREF 

Examples 

<-- VERS 

--> 202 


2 Current protocol level is 2 


<-- VERS 2 
--> 302 
2 My max protocol level is 10 


<-- VERS 11 
--> 402 
10 Falling back to level 10 


<-- VERS BAL 
--> 510 
1 Syntax error 
6.3.3.0 QUIT 
Description 
Terminates the connection. 
quit-cmd = "QUIT" CRLF 
Possible answers 
201: Termination of the connection 


quit-answer = "201" [answertext] CRLF 
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Example 


<-- QUIT 
--> 201 Closing connection. Bye. 


6.33.65 LIST 
Description 
To obtain a list of newsgroups and sub-hierarchies in the requested 
hierarchies, the command LIST is used. The status of the hierarchies 
is also given. The highest level consists of all top-level 


hierarchies and is labeled "*". It can be obtained this way, too. 


The data consist of a newsgroup- or hierarchy-name/status indicator 
pair per line. Name and status indicator must be separated by at 


least one white space. The status indicator is a single word (see 
Section 6.4). The interpretation is not case sensitive. 
list-cmd = "LIST" ( WSP "*" / 1* (WSP name)) CRLF 


Possible answers 


401: Permission denied 
510: Syntax error 
610: Normal response with all requested data 


list-answer = "610" [answertext] CRLF 
*(listdata CRLF) 
Ta WA CREE: 

list-answer =/ "401" [answertext] CRLF 
text CRLF 
Mor (CRUE 

list-answer =/ "510" [answertext] CRLF 
text CRLF 
"." CRLF 


listdata = name WSP list-status 


The list-status is the status of a newsgroup or hierarchy according 
to Section 6.4. 


list-status = "Complete" 
"Incomplete" 
"Obsolete" 
"Unknown" 
"Unmoderated" 
"Readonly" 


YN >= >= > i 
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"Removed" ; list-status is case-insensitive 


mples 


LIST * 

610 data follow 
alt Incomplete 
comp Complete 
de Incomplete 
rec Complete 
sub Obsolete 


LIST de 

610 data follow 
de.admin Complete 
de.alt Incomplete 
de.comm Complete 
de.comp Complete 
de.etc Complete 
de.markt Complete 
de.newusers Complete 
de.org Complete 
de.rec Complete 
de.sci Complete 
de.soc Complete 
de.answers Moderated 
de.test Unmoderated 


LIST foo 
610 data follow 
foo Unknown 


LIST 
510 Syntax error 
missing parameter hierarchy 


LIST de 
401 Something is wrong 
Permission denied 
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To obtain a recursive list of newsgroups and sub-hierarchies in the 


named hierarchy, the command LSTR is used. The status of the 
hierarchies is also given. 
level hierarchies and is labeled 


too. 


"Min" 


The highest level consists of all top- 
It can be obtained this way, 


The use of "*" as a wildcard pattern following the beginning of a 


hierarchy name is also possible; so a "LSTR de.a*" 
list of all newsgroups and hierarchies starting with "de.a". 


"Min 


lstr-cmd = "LSTR" ( WSP / 1*(WSP name ["*" / ".*"]) ) CRLF 


Possible answers 


401: Permission denied 
510: Syntax error 
610: Normal answer with all requested data 


lstr-answer = "610" [answertext] CRLF 


*(listdata CRLF) 


would return a 


m IE “CREF 
lstr-answer =/ "401" 
text CRLF 
"¿" CRLF 
lstr-answer =/ "510" 
text CRLF 
" " CRLF 


listdata = 


[answertext] CRLF 


[answertext] CRLF 


name WSP list-status 


The list-status is the status of a newsgroup or hierarchy according 


to Section 6.4. 
list-status = "Complete" 
"Incomplete" 
"Obsolete" 
"Unknown" 
"Unmoderated" 
"Readonly" 
"Moderated" 
"Removed" 
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Example 


<-- LSTR de.admin 

--> 610 recursive mode 
de.admin Complete 
de.admin.infos Moderated 
de.admin.lists Moderated 
de.admin.misc Unmoderated 
de.admin.net-abuse Complete 
de.admin.net-abuse.announce Moderated 
de.admin.net-abuse.mail Unmoderated 
de.admin.net-abuse.misc Unmoderated 
de.admin.net-abuse.news Unmoderated 
de.admin.news Complete 
de.admin.news.announce Moderated 
de.admin.news.groups Unmoderated 
de.admin.news.misc Unmoderated 
de.admin.news.nocem Unmoderated 
de.admin.news.regeln Unmoderated 


6.3.3.8. HIER 
Description 
The command HIER lists all information available about the hierarchy. 


With the data header "Name", a new data block for each hierarchy is 
started. The header "Name" gives the name of the hierarchy. The 


data headers are described in Section 6.3.4. The default is to 
transmit all available information. It can be limited to a list of 
desired headers ("Name" and "Status" are always given). A set of 


comma-separated headers, as an option to the HIER command, will 
return the requested header fields. 


hier-cmd = "HIER" 1*(WSP name) [WSP selection] CRLF 

selection = *( "," header ) ; Describes the data fields 
; that are requested 

header = ALPHA *( ALPHA / "-" ) ; According to section 6.3.4 


Example for selection 


‚Followup,Description : For all entries list Name, Status, Followup 
and Description 


Possible answers 


401: Permission denied 
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510: Syntax error 
611: Regular answer with all requested data 


hier-answer = "611" [answertext] CRLF 
*(hierdata CRLF) 
Ma “CRE 

hier-answer =/ "510" [answertext] CRLF 
* (text CRLF) 
mo" CREF 

hier-answer =/ "401" [answertext] CRLF 
* (text CRLF) 
"." CRLF 

hierdata = "Name:" WSP text CRLF 
"Status:" WSP text CRLF 
*(header ":" WSP text CRLF) 


[ ("Ctl-PGP-Key:" CRLF PGP-answer / 
"Mod-PGP-Key:" CRLF PGP-answer) ] 


PGP-answer: The exact format is described in Section 6.7. 
Examples 


<-- HIER de 

--> 611 Data coming 

Name: de 

Status: Complete 

Serial: 20020823120306 

Description: Internationale deutschsprachige Newsgruppen 
Netiquette: http://www.kirchwitz.de.example/”amk/dni/netiquette 
FAO: http://www.kirchwitz.de.example/"amk/dai/einrichtung 
Ct1-Send-Adr: moderator@dana.de.example 

Ct1-Newsgroup: de.admin.news.announce 

Mod-Wildcard: %s@moderators.dana.de.example 

Language: DE 

Charset: ISO-8859-1 

Encoding: text/plain 

Newsgroup-Type: Discussion 

Hier-Type: Global 

Comp-Length: 14 

Date-Create: 19920106000000 


<-- HIER bln 
--> 401 
Permission denied 
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--> 510 Syntax error 
missing parameter hierarchy 


OE 


Des 


9. DATA 


cription 


The DATA command corresponds to the HIER command, 
.3.8, but it is used for information about a newsgroup. A summary 
of codes can be found in Section 6.3.4. 


6.3 


dat 


a-cmd = 


"DATA" 1* (WSP name) [WSP selection] CRLF 


Possible answers 


401 
510 
612 


data-answer = 


data-answer =/ 


data-answer =/ 


dat 


Exa 


--> 


Grau, 


: Permission denied 
: Syntax error 
: Regular answer with all requested data 


"612" [answertext] CRLF 
*(datadata CRLF) 

"SU CRUE 

"510" [answertext] CRLF 
text CRLF 

Wa “CREE 

"401" [answertext] CRLF 
text CRLF 

we “CREE 


October 2006 


as explained in 


<dcoulm-moderators@linux-config.de.example> 


adata "Name:" WSP text CRLF 
"Status:" WSP text CRLF 
* (header ":" WSP text CRLF) 
[ ("Ctl-PGP-Key:" CRLF PGP-answer / 
"Mod-PGP-Key:" CRLF PGP-answer) ] 
mples 
<-- DATA de.comp.os.unix.linux.moderated 
612 data follow 
Name: de.comp.os.unix.linux.moderated 
Status: Moderated 
Serial: 20020823120312 
Description: Linux und -Distributionen. 
Charter: http://www.dana.de.example/mod/chartas/de.html 
Netiquette: http://www. kirchwitz.de.example/~amk/dni/netiquette 
et al. Experimental 
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Netiquette: ftp://ftp.fu-berlin.de.example/doc/usenet/german 
/Netiquette 
Mod-Sub-Adr: dcoulm-moderators@linux-config.de.example 
Mod-Group-Info: http://wpxx02.toxi.uni-wuerzburg.de.example 
/"dcoulmod/ 
Newsgroup-Type: Discussion 


<-- DATA de.foo 

--> 612 data follow 
Name: de.foo 
Status: Unknown 


<-- DATA de 
=-> 401 
Permission denied 


<-- DATA 
--> 510 Syntax error 
missing parameter newsgroup 


6.3.3.10. GETP 


Description 
GETP is used for server-server communication. It requests the data 
for the hierarchy specified by the parameter "name". The format of 
the data is the same as for the commands "HIER" and "LIST". If "*" 
is given as hierarchy name, all data the server is offering will be 
transmitted. 


The "timestamp" attached to a package consists of the date and time 
that the package was created. The timestamp for a package is 
transmitted together with the package data by the server and marks a 
specific revision for the package data. 


when a client requests a package with GETP, it transmits the 
timestamp attached to the package in its database so that the server 
can check whether the data on the client side is still valid or if it 
is too old. If the data on the client side is still valid, a 213 
answer is sent, so the client knows that its data is OK. If the 
timestamp is "0", the server is forced to transmit the data. 
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Timestamps set by the server must be increasing and may not be more 
than 12 hours in the future. 


The data for a successful request are signed and sent in ASCII armor 


according to 


its 
sec 


get 


use 


pas 


timestamp 


[RFC2440], 


so a client can check the signature or ignore 


The actual data will be surrounded by the armor start and end 


tions, 


p-cmd 


rname 


sword 


according to Section 6.2 of [RFC2440]. 


"GETP" WSP username WSP password WSP timestamp 


WSP 
*1( 
*1( 


( name / "*" ) CRLF 
VCHAR ) / "0" ; Length 
VCHAR ) / "0" ; Length 
utc-time / ; date and ti 
TON ; force the t 


Possible answers 


213: 
411: 
430: 
510: 
613: 


getp-answer 


getp-answer 


getp-answer 


getp-answer 


getp-answer 


Current data at the client side 
No hierarchy with that name 
Permission denied 

Syntax error 

Hierarchy data 


"613" [answertext] CRLF 
pgp-ascii-armor-start ; 
*(getpdata CRLF) 
pgp-ascii-armor-end A 
"." CRLF 

"213" [answertext] CRLF 
text CRLF 

wh CREE 

"430" [answertext] CRLF 
text CRLF 

MATO CRLF 

"411" [answertext] CRLF 
text CRLF 

me CREF 

"510" [answertext] CRLF 
text CRLF 

A 


of VCHAR >= 1 
of VCHAR >= 1 


me of the last retrieval 
ransmission of data 


this is according to [RFC2440] 


this is according to [RFC2440] 


pgp-ascii-armor-start and the pgp-ascii-armor-end are built according 
[RFC2440], S 


to 


Grau, 


et al. 


ection 6.2., "Forming AS 


Experimental 


CIT Armor". 
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getpdata = "Name: " WSP text CRLF 


"Status:" WSP text CRLF 

"Serial:" WSP timestamp CRLF 

*(header ":" WSP text CRLF) 

[("Ct1-PGP-Key:" CRLF PGP-answer / 
"Mod-PGP-Key:" CRLF PGP-answer) ] 


Examples 


<-- GETP 0 0 0 humanities 
--> 615 data follow 


Grau, 


Hash: SHA1 


Name: humanities 

Status: Complete 

Serial: 20020821094529 

Description: Branches of learning that investigate human 

constructs and concerns as opposed to natural processes. 

Netiquette: ftp://rtfm.mit.edu.example/pub/usenet 
/news.announce.newusers 
/A_Primer_on_How_to_Work_With_the_Usenet_Community 

Rules: http://www.uvv.org.example/docs/howto.txt 

Ctl-Send-Adr: group-admin@isc.org.example 

Ctl-Newsgroup: news.announce.newgroup 

Language: EN 

Charset: US-ASCII 

Encoding: text/plain 

Newsgroup-Type: Discussion 

Hier-Type: Global 

Comp-Length: 14 

Date-Create: 19950417143009 


Name: humanities.answers 

Status: Moderated 

Serial: 20020821094533 

Description: Repository for periodic USENET articles. (Moderated) 
Mod-Sub-Adr: news-answers@mit.edu.example 

Mod-Adm-Adr: news-answers-request@mit.edu.example 
Newsgroup-Type: Announce 

Date-Create: 19950725182040 

Name: humanities.classics 


Perred 


Version: GnuPG v1.0.7 (IRIX64) 


iD8DBOE9Z3/Wn13IY1dLZg8RAhnWiAJ4y70+3FzBpRjYJj]2HWwXyG2g8Fo0CfeEsH 
rRynPhhjveiY/XBkkrrZFho= 
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<-- GETP 0 0 19990909101000 de 
--> 213 
You are up-to-date 


<-- GETP foo 
--> 510 Syntax error 
Missing parameters 


<-- GETP guest test 0 de 
--> 430 
You have no permission to retrieve the data 


6.3.3.11. GETA 
Description 


The GETA command is used for server-server communication; it is used 
to collect authoritative data and will request packages that the 
server is authoritative for. A package is the authoritative data 
either for a newsgroup or a hierarchy. Each package has a 
"timestamp" attached to mark the revision of the package. This 
timestamp is set by the server to the date of the last modification 
of the package data in UTC format. A timestamp of "0" indicates that 


the package MUST be retrieved. If the retrieving client has a recent 
package (i.e., no modification on the authoritative server), the 
server sends only a 215 response. The format of the data is the same 


as that for the commands "HIER" and "LIST". 


geta-cmd = "GETA" WSP username WSP password WSP 
timestamp WSP name CRLF 


Possible answers 


215: The client already has the current data 
430: Permission denied 

411: No hierarchy with that name 

510: Syntax error 

615: Regular answer with all requested data 
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geta-answer = "615" [answertext] CRLF 


pgp-ascii-armor-start ; this is according to [RFC2440] 
*(getadata CRLF) 

pgp-ascii-armor-end ; this is according to [RFC2440] 
"SU CREF 


geta-answer =/ "215" [answertext] CRLF 


text CRLF 
" " CRLF 


geta-answer =/ "430" [answertext] CRLF 


text CRLF 
" " CRLF 


geta-answer =/ "411" [answertext] CRLF 


text CRLF 
" " CRLF 


geta-answer =/ "510" [answertext] CRLF 


text CRLF 
" " CRLF 


getadata = "Name: " WSP text CRLF 


"Status:" WSP text CRLF 

"Serial:" WSP timestamp CRLF 

*(header ":" WSP text CRLF) 

[("Ct1-PGP-Key:" CRLF PGP-answer/ 
"Mod-PGP-Key:" CRLF PGP-answer) ] 


Example 


<-- GETA 0 0 0 humanities 
--> 613 data follow 


Grau, 


Hash: SHA1 


Name: humanities 

Status: Complete 

Serial: 20020821094529 

Description: Branches of learning that investigate human 

constructs and concerns as opposed to natural processes. 

Netiquette: ftp://rtfm.mit.edu.example/pub/usenet 
/news.announce.newusers 
/A_Primer_on_How_to_Work_With_the_Usenet_Community 

Rules: http://www.uvv.org.example/docs/howto.txt 

Ctl-Send-Adr: group-admin@isc.org.example 

Ctl-Newsgroup: news.announce.newgroup 

Language: EN 

Charset: US-ASCII 

Encoding: text/plain 

Newsgroup-Type: Discussion 

Hier-Type: Global 
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Comp-Length: 14 
Date-Create: 19950417143009 


Name: humanities.answers 

Status: Moderated 

Serial: 20020821094533 

Description: Repository for periodic USENET articles. (Moderated) 
Mod-Sub-Adr: news-answers@mit.edu.example 

Mod-Adm-Adr: news-answers-request@mit.edu.example 
Newsgroup-Type: Announce 

Date-Create: 19950725182040 


Name: humanities.classics 


Seren BEGIN PGP SIGNATURE----- 
Version: GnuPG v1.0.7 (IRIX64) 


iD8DBOE9ZJ/Wn13IY1ALZg8RAhWiAJAy70+3FZBpRjYJj2HWWXyG2g8FoQCfeEsH 
rRynPhhjveiY/XBkkrrZFho= 
=muK4 


6.3.3.12. Unknown Commands and Syntax Errors 


If a command is recognized as unknown, a 519 return code (unknown 
command) is given. If an error occurs after the command string 
(e.g., a missing parameter), a 510 return code (Syntax error: Missing 
parameter) is given. 


6.3.4. Data Headers 


The following paragraphs describe key words and key terms that 
support retrieval and storing of information. Every header has a 
unique English name. 


The content of a header is inheritable within a hierarchy, as long as 


the header is marked as inheritable. The content is the default 
value for all downstream newsgroups and sub-hierarchies. For 
example, in the hierarchy "de", the language header has the value 
"DE" (German); therefore, this value is "DE" for all newsgroups in 
this hierarchy, except for those that explicitly define a language 
code of their own. 


Hierarchies and newsgroups must have at least values for the headers 
"Name" and "Status". Unknown hierarchies or groups get the status 
"Unknown". 
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A header 


may be uppercase, 


lowercase, or any mixture of upper- and lowercase. 


It is recommended that the first letter of the header and the first 
letter after a dash be uppercase and that all other characters be 


lowercase. 
Name 
Header: 


Used for: 
Mandatory: 


Repeatable: 


Comment: 
Example: 


Used for: 
Mandatory: 
Repeatable: 


Description: 


Comment: 
Example: 
Status 
Header: 


Used for: 
Mandatory: 


Inheritable: 


Repeatable: 


Description: 


Comment: 
Example: 


Used for: 
Mandatory: 
Repeatable: 


Description: 


Comment: 
Example: 


et al. 


Inheritable: 


Description: 


Name 


hierarchy 

yes 

no 

no 

Name of a hierarchy. 


Start of a new data block. 
Name: comp 

newsgroup 

yes 

no 

Name of a newsgroup 

Start of a new data block. 


Name: de.admin.news.announce 


Status 


hierarchy 

yes 

no 

no 

Status of a hierarchy. 


For a detailed description, see Section 6.4. 


Status: Hierarchy-Complete 
newsgroup 

yes 

no 


Status of a newsgroup. 
For a detailed description, 
Status: Group-Moderated 


see Section 6.4. 
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Serial 
Header: 


Used for: 
Mandatory: 
Inheritable: 
Repeatable: 
Description: 
Comment : 
Example: 


Used for: 
Mandatory: 
Inheritable: 
Repeatable: 
Description: 
Comment : 
Example: 
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Serial 


hierarchy 

no 

no 

no 

Timestamp for hierarchy data. 

For a detailed description, see Section 6.4. 
Serial: 20020821102413 


newsgroup 

no 

no 

no 

Timestamp for newsgroup data. 

For a detailed description, see Section 6.4. 
Serial: 20020821102413 


Group for followup 


Header: 

Used for: 
Mandatory: 
Repeatable: 
Description: 


Comment : 


Example: 


Grau, et al. 


Followup 


newsgroup 

no 

no 

Name of the newsgroup that will take the followup 
postings of a moderated group. 

The value can be used as default value for the 


"Followup-To:" header on postings to a moderated group. 
This value is only useful on groups that are moderated 
(Status Group-Moderated) and have a dedicated discussion 


group. 


Followup: bln.announce.fub.zedat.d 
(for the moderated group bln.announce.fub.zedat) 
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Short description 


Header: 


Used for: 
Mandatory: 


Inheritable: 


Repeatable: 


Description: 


Example: 


Used for: 
Mandatory: 
Repeatable: 


Description: 


Comment : 


Example: 


Charter-URL 


Description 


hierarchy 

no 

no 

no 

Short description of a hierarchy. 

Description: Angelegenheiten, die den Grossraum Berlin 
betreffen 


(for the hierarchy bln) 


newsgroup 
no 

no 

Short description of a newsgroup. 

This information is often presented to the news reader 
upon selection of the newsgroup, and it should be a 
brief but meaningful description of the topic. 
Description: Technisches zur Newssoftware 

(for de.admin.news.software) 


Header: Charter 
Used for: hierarchy 
Mandatory: no 
Inheritable: no 
Repeatable: yes 
Description: URL that points to the charter of a hierarchy. 
Example: Charter: ftp://ftp.fu-berlin.de.example/doc/news/bln/bln 
(for the hierarchy bln) 
Used for: newsgroup 
Mandatory: no 
Repeatable: yes 
Description: URL that points to the charter of a newsgroup. 
Comment: This information should be presented to the 
news reader upon selection of the newsgroup. 
Example: Charter: ftp://ftp.fu-berlin.de.example/doc/news/bln 
/obln.markt.arbeit 
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Netiquette-URL 


Header: Netiquette 
Used for: hierarchy 
Mandatory: no 


Inheritable: yes 
Repeatable: yes 
Description: URL that points to the netiquette of a hierarchy. 


Comment : Since the netiquettes are often valid for 
a complete hierarchy, this is inheritable. 
Example: Netiquette: 


http://www.kirchwitz.de.example/”amk/dni/netiquette 


Used for: newsgroup 
Mandatory: no 

Repeatable: yes 

Description: URL for Netiquette. 


Comment : If a group has some special rules, this is the 
pointer to these rules. 
Example: Netiquette: http://go.to.example/bln.markt 


(for bln.markt) 


Frequently Asked Questions (FAQ) 


Header: FAQ 
Used for: Newsgroup 
Mandatory: no 


Repeatable: yes 
Description: URL for the FAQ of a newsgroup. 
Example: FAQ: http://www.dard.de.example/ 


Administration rules 


Header: Rules 
Used for: hierarchy 
Mandatory: no 


Inheritable: yes 

Repeatable: yes 

Description: URL pointing to a document that describes the rules for 
creating, deleting, or renaming newsgroups in this 
hierarchy. 

Comment: Normally inherited from the toplevel hierarchy. 
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Example: 


Control Email 


Header: 


Used for: 
Mandatory: 
Inheritable: 
Repeatable: 
Description: 
Comment : 
Example: 


Netnews Administration System (NAS) 


Rules: http://www.kirchwitz.de.example/"amk/dai 


/einrichtung 


Ct1-Send-Adr 


hierarchy 

no 

yes 

yes 

Email address of the sender of control messages. 
Multiple addresses are valid. 

Ctl-Send-Adr: group-admin@isc.org.example 


Control newsgroup 


Header: Ctl-Newsgroup 

Used for: hierarchy 

Mandatory: no 

Inheritable: yes 

Repeatable: yes 

Description: Name of the newsgroup that will get the postings for 
checkgroups, rmgroup, and newsgroup control messages. 

Example: Ctl-Newsgroup: de.admin.news.groups 

Moderators 

Header: Mod-Wildcard 

Used for: hierarchy 

Mandatory: no 

Inheritable: yes 

Repeatable: no 

Description: Moderator wildcard for this hierarchy. 

Comment: This information can be used for the configuration of 
the news software, for example, to configure the 
moderators file in INN. 

Example: Mod-Wildcard: %s@moderators.dana.de.example 
(for the hierarchy de) 
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Submission address 


Header: 


Used for: 
Mandatory: 
Repeatable: 
Description: 
Comment : 


Example: 


Header: 


Used for: 
Mandatory: 
Repeatable: 
Description: 
Comment : 


Example: 


Info-URL 
Header: 
Used for: 
Mandatory: 


Repeatable: 
Description: 


Example: 


et al. 


Moderator’s address 


Mod-Sub-Adr 


newsgroup 

no 

yes 

Email address for submissions to the newsgroup. 

If there is no "Mod-Sub-Adr" for a moderated newsgroup, 
"Mod-Wildcard" of the hierarchy is used. This is useful 
only for moderated groups (Status Group-Moderated). 
Mod-Sub-Adr: news-answers@mit.edu.example 

(for the newsgroup news.answers) 


(email) 
Mod-Adm-Adr 


newsgroup 

no 

yes 

Email address of the moderator of the newsgroup. 

If there is no code "Mod-Adm-Adr" for a moderated 
newsgroup, "Mod-Wildcard" of the hierarchy is used. 
This is useful only for moderated groups 

(Status Group-Moderated). 

Mod-Adm-Adr: news-answers-request@mit.edu.example 
(for the newsgroup news.answers) 


Mod-Group-Info 


newsgroup 

no 

yes 

URL that points to a document where the moderator 
presents information about the newsgroup and the 
submission of articles. 

Mod-Group-Info: http://www.example.org/cola-submit.html 
(for comp.os.linux.announce) 
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Language 

Header: Language 

Used for: hierarchy 

Mandatory: no 

Inheritable: yes 

Repeatable: yes 

Description: The language that will normally be used in postings. 

Comment : The notation is according to the "Content-Language" 
field of [RFC2616]. The languages not 
preferred are enclosed in parentheses. 

Example: Language: DE 
(for the hierarchy de) 

Used for: newsgroup 

Mandatory: no 

Repeatable: yes 

Description: The language that will normally be used in postings. 

Comment : The notation is according to the "Content-Language" 
field of [RFC2616]. The languages not 
preferred are enclosed in parentheses. 

Example: Language: TR 
Language: DE 
Language: (EN) 
(for the newsgroup bln.kultur.tuerkisch) 

Charset 

Header: Charset 

Used for: hierarchy 

Mandatory: no 

Inheritable: yes 

Repeatable: yes 

Description: Charset that will normally be used in postings in th 
hierarchy. 

Comment : The complete set of charset names is defined by 
[REC2277] and the IANA Character Set registry [IANA-CS]. 
The charsets that are not the preferred charsets are 
enclosed in parentheses. 

Example: Charset: ISO-8859-1 
(for the hierarchy de) 

et al. Experimental [Page 


Grau, 


REC 4707 


Netnews Administration System (NAS) October 2006 


Used for: newsgroup 

Mandatory: no 

Repeatable: yes 

Description: Charset that will normally be used in 
postings in this group. 

Comment : The complete set of charset names is defined by 
[REC2277] and the IANA Character Set registry 
[IANA-CS]. The charsets that are not the preferred 
charsets are enclosed in parentheses. 

Example: Charset: ISO-8859-9 
Charset: ISO-8859-1 
(for the newsgroup bln.kultur.tuerkisch) 

Encoding 

Header: Encoding 

Used for: hierarchy 

Mandatory: no 

Inheritable: yes 

Repeatable: yes 

Description: Encoding for this hierarchy according to MIME [RFC2045]. 

Comment: This is the media type used in this hierarchy; a list of 
registered media types can be found at [IANA-MT]. The 
encodings not preferred are enclosed in parentheses. 

Example: Encoding text/plain 

Used for: newsgroup 

Mandatory: no 

Repeatable: yes 

Description: Encoding for this newsgroup according to MIME [RFC2045]. 

Comment This is the media type used in this newsgroup; a list of 
registered media types can be found at [IANA-MT]. The 
encodings not preferred are enclosed in parentheses. 

Example: Encoding: text/plain 
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Type of newsgroup 


Header: 


Used for: 
Mandatory: 


Inheritable: 


Repeatable: 


Description: 


Comment : 


Example: 


Used for: 
Mandatory: 
Repeatable: 


Description: 


Comment: 
Example: 


Newsgroup-Type 


hierarchy 

no 

yes 

yes 

Default newsgroup type in this hierarchy. 

This header has no concrete meaning for a hierarchy but 
is used for the inheritance to newsgroups in the 
hierarchy. 

Specification of the types can be found in Section 6.5. 
Newsgroup-Type: Discussion 

(for the hierarchy de) 


newsgroup 

no 

yes 

Type of newsgroup. 

Specification of the types can be found in Section 6.5. 
Newsgroup-Type: Announce 

(for de.admin.news.announce) 


Type of hierarchy 


Header: 


Used for: 
Mandatory: 


Inheritable: 


Repeatable: 


Description: 


Comment: 
Example: 


et al. 


Hier-Type 


hierarchy 

no 

yes 

yes 

Type of hierarchy. 

Specification of the types can be found in Section 6.6. 
Hier-Type: Regional 

(for hierarchy bln) 
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Regional or 
Header: 


Used for: 
Mandatory: 


Inheritable: 


Repeatable: 


Description: 


Comment : 


Example: 


Name length 
Header: 


Used for: 
Mandatory: 


Repeatable: 


Example: 


Inheritable: 


Description: 
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Organizational Area 
Area 


hierarchy 

no 

yes 

yes 

Description of the geographical region or organization 
of this hierarchy. 

This code is useful when the hierarchy type 
(Hier-Type) is "Regional" or "Organization". 

Area: Grossraum Berlin 

(for the hierarchy bln) 


of group names 
Name-Length 


hierarchy 

no 

yes 

no 

Maximum length of a newsgroup name. 
Name-Length: 72 

(for the hierarchy bln) 


Component length of group names 


Header: 


Used for: 
Mandatory: 


Inheritable: 


Repeatable: 


Description: 


Example: 


et al. 


Comp-Length 


hierarchy 

no 

yes 

no 

Maximum length of a single component in the newsgroup 
name. 

Comp-Length: 14 

(for the hierarchy de) 
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Article length 


Header: 


Used for: 
Mandatory: 


Inheritable: 


Repeatable: 


Description: 


Comment : 


Example: 


Used for: 
Mandatory: 
Repeatable: 


Description: 


Example: 


Header: 


Used for: 
Mandatory: 


Repeatable: 


Comment: 
Example: 


Used for: 
Mandatory: 
Repeatable: 


Description: 


Comment: 
Example: 


et al. 


Inheritable: 


Description: 


Article-Length 


hierarchy 

no 

yes 

no 

Maximum length of an article in bytes. 

This header has no concrete meaning for a hierarchy but 
is used for the inheritance to newsgroups in the 
hierarchy. 
Article-Length: 50000 

newsgroup 

no 

no 

Maximum length of an article in bytes. 
Article-Length: 50000 


Date of creation 


Date-Create 


hierarchy 

no 

yes 

no 

Creation date of a hierarchy; can even be in the future. 
The format is the same as in the DATE command. 
Date-Create: 19970330101514 


newsgroup 
no 

no 

Creation date of a newsgroup; can even be in the future. 
The format is the same as in the DATE command. 
Date-Create: 19970330101514 
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Header: 


Used for: 
Mandatory: 


Repeatable: 


Comment: 
Example: 


Used for: 
Mandatory: 
Repeatable: 


Description: 


Comment: 
Example: 
Successor 
Header: 


Used for: 
Mandatory: 


Inheritable: 


Repeatable: 


Description: 


Example: 


Used for: 
Mandatory: 
Repeatable: 


Description: 


Example: 


et al. 


Inheritable: 


Description: 
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Date of removal 


Date-Delete 


hierarchy 

no 

yes 

no 

Date of removal of a hierarchy; 
future. 

The format is the same as in the DATE command. 
Date-Delete: 19970330101514 


can even be in the 


newsgroup 
no 

no 

Date of removal of a newsgroup; 
future. 

The format is the same as in the DATE command. 
Date-Delete: 19970330101514 


can even be in the 


Replacement 


hierarchy 

no 

no 

yes 

Name of the hierarchy that replaced a removed hierarchy 
if status is "Hierarchy-Obsolete" or will replace a 
hierarchy if the date of removal is in the future. 
Replacement: de 

(for the hierarchy sub) 


newsgroup 

no 

yes 

Name of the newsgroup or newsgroups that will replace a 
removed newsgroup if status is "Group-Removed" or will 
replace the newsgroup if the date of removal is in the 

future. 

Replacement: bln.markt.arbeit 

(for bln.jobs) 
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Header: Source 


Used for: 
Mandatory: 
Inheritable: 
Repeatable: 
Description: 


Example: 


hierarchy 

no 

yes 

no 

Pointer to an organization or person responsible 
for this hierarchy. SHOULD be a URL or an email 
address. 

Source: http://www.dana.de.example/mod/ 

(for the hierarchy de) 


E: This is for tracking the maintainer of a hierarchy. 


Control PGP 


key 


Header: Ct1l-PGP-Key 

Used for: hierarchy 

Mandatory: no 

Inheritable: yes 

Repeatable: yes 

Description: PGP key (with additional information: key owner, key-id, 
etc.) of the sender of control messages in this 
hierarchy. 

Comment: The exact format is described in Section 6.7. 

Example: Ct1-PGP-Key: 


Grau, et al. 


de.admin.news.announce 

1024 

D3033C99 

http: //www.dana.de.example/mod/pgp/dana.asc 

ftp: //ftp.isc.org.example/pub/pgpcontrol/PGPKEYS.gz 
5B BO 52 88 BF 55 19 4F 66 7D C2 AE 16 26 28 25 
2.6.3ia 


a AHRWG 


K-Version: 2.6.3ia 

K- 

K-mQCNEALZ+Xfm/WDCEMXM4 8gK1P1KG6TkV3SLbxXt 4CnzpGMOtOMa 
K-Hj1HqM1wEGUHD5hw/BL/heR5Tq+C5IEyxQOmYwkrgeVFMOz/rAQ 
as] 

K-SDw+iQgAAtN6zrYOhHFBpt+ 
K-VpvRovMz+1SOy9Zcsbs+5t 8P j9ZVAQy£xBkgqD5A= 

K-=Xwgc 
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Moderator's PGP key 
Header: Mod-PGP-Key 
Used for: newsgroup 
Mandatory: no 
Repeatable: yes 
Description: Public PGP key (with additional information: key owner, 
key-id, etc.) of this newsgroup's moderator. 
Comment : The exact format is described in Section 6.7 
Example: See Section 6.7. 
6.4. Status Indicators 
The status indicator uniquely determines the status of a hierarchy or 
newsgroup. The indicator is case insensitive. 
Indicator Type Description 
Complete hierarchy Authorized, complete known hierarchy 
Incomplete hierarchy Not completely known hierarchy (like free.*) 
Obsolete hierarchy Obsolete hierarchy; should contain only 
newsgroups with status "Removed" 
Unknown hierarchy No information available; unknown hierarchy 
Unmoderated newsgroup Posting allowed; unmoderated 
Readonly newsgroup Posting not allowed 
Moderated newsgroup Moderated group; articles must be sent to 
the moderator 
Removed newsgroup Deleted or renamed newsgroup; no posting or 
transport 
Unknown newsgroup Unknown group; no information available 
6.5. Newsgroup Types 
A Newsgroup Type is a comprehensive overview about some 
characteristics of a newsgroup, being a test group, a binary group, 
or some other kind. The Newsgroup Type is case insensitive. 
Type Meaning 
Discussion Discussion (text postings) 
Binary (Encoded) binary postings 
Sources Source postings (e.g., comp.unix.sources) 
Announce Announcements, press releases, RfD/CfV 
Test Test postings, sometimes reflectors (e.g., de.test) 
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Robots Automatic postings (like the former comp.mail.maps) 
Experiment Experimental, other 


6.6. Hierarchy Types 


To describe a hierarchy, the following Hierarchy Types are used. 
These Types are used to mark some properties of a news hierarchy. 
They are case insensitive. 


Regional 


Alt 


Non-commercial 


Commercial 
Organization 


6.7. PGP Keys 


Meaning 

International, global hierarchy 

(e.g., the hierarchies comp, de, rec) 

Regional hierarchy 

(e.g., the hierarchies ba, bln, tor) 

Alternative hierarchy, simpler rules for 

creating a group, no formal structure 

(e.g., the hierarchy alt) 

Only for personal use; commercial use is prohibited 
(e.g., the hierarchy de) 

Commercial use permitted (e.g., the hierarchy biz) 
Hierarchy bound to an organization 

(e.g., the hierarchy gnu) 


PGP keys for Ctrl-PGP-Key and Mod-PGP-Key are transmitted in the 
following structure: 


PGP-answer = "Vv" 
"yn 
"B" 
" I " 
"E " 


SP Version CRLF 
SP User-ID CRLF 
SP Bits CRLF 

SP Key-ID CRLF 
SP Finger CRLF 


*("L" SP Location CRLF) 
* ("K-" Keyblock CRLF) 


"kg" 
Version = text 
User-ID = text 
Bits = text 
Key-ID = text 
Finger = text 


Location = text 
Keyblock = text 
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Name Mandatory Description 

Keyblock yes Public key block in ASCII armor format 
[RFC2440] 

Version yes PGP-Version 

User-ID no Key user id 

Bits no Number of bits 

Key-ID no Key id, without leading "0x" 

Finger no Fingerprint 

Location no URL that points to the public key 


yphen following the code indicates that the block is continued on 
next line. In the last message row, there MUST be white space 


er the code; this is also true for a single line code. 
ample 

HIER de 

611 Data coming 

Name: de 


Status: Hierarchy 

| 

Ct1l-PGP-Key: 

de.admin.news.announce 

1024 

D3033C99 

http: //www.dana.de.example/mod/pgp/dana.asc 
ftp://ftp.fu-berlin.de.example/unix/news/pgpcontrol/PGPKEYS.gz 
5B BO 52 88 BF 55 19 4F 66 7D C2 AE 16 26 28 25 

2.6.3ia 


nN<HrHmHQVc 


K-Version: 2.6.3ia 

K- 
K-mQOCNAzGeB/YAAAEEALZ+Xfm/WDCEMXM48gK1P1KG6TKV3SLbXt ACnzpGMtOM 
K-Hj1HaU6Xco5i jAugM1wEGUHD5hw/BL/heR5Tg+C5IEyX0QmYwkrgeVFMO/rA 
era] 
K-SDw+IdOJPFO9YAWOILOgAALN6ZLYOhHFBp+68h9k674Yg9IHQgJ3BWARJJFEPKO 
K-VpvRovMz+1SOy9Z2csbs+5t8P J9ZVAQyfxBkgD5A= 

K-=Xwgc 
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7. 


Specification of the NAS Protocol (UDP) 


UDP is intended for reading programs (news readers); it is not in the 
scope of this document. The use of UDP for NAS will be described in 
a separate paper. 


IANA Considerations 


The IANA has registered the application/nasdata media type as defined 
by the following information: 


Media type name: application 
Media subtype name: nasdata 
Required parameters: none 
Optional parameters: level 


The NAS protocol level number for the enclosed 
NAS data package. If not present, the 
protocol level defaults to 1. 


Encoding scheme: NAS data is plain text; no special encodings are 
needed. 


Security considerations: see below 
Security Considerations 


Security issues are only addressed in respect to server-server 
communication in this protocol level. Username and password 
combinations in the GETA and GETP commands can be used to make sure 
that connections are only accepted from authorized clients. PGP keys 
according to [RFC2440] are used to sign NAS data in server-server 
communication in order to validate that the data is authentic and has 
not been tampered with. 


Every server does have the possibility (in both server-server and 
server-client communication) to deny some commands or the whole 
connection according to the client’s IP number. 


No mechanisms are defined in the current protocol level to allow a 
client to validate that it is talking to a legitimate server or that 
the data it receives is authentic. 


A stronger authentication scheme will be provided in a higher 
protocol level. 


Grau, et al. Experimental [Page 44] 


REC 4707 Netnews Administration System (NAS) October 2006 


10. Response Codes (Overview) 


Code Description 


100 Command overview, Information, command description (HELP) 

101 Information about connection, client and server (INFO) 

200 Greeting message (Connection Setup) 

201 Termination of the connection (QUIT) 

202 Returns current protocol level (VERS) 

213 Valid data at the client side (GETP) 

215 The client already has the current data (GETA) 

300 Time in UTC (DATE) 

302 Answer to a successful request (VERS) 

400 Indicates that the server is not giving any information (INFO) 
401 Permission denied (LIST, LSTR, HIER, DATA) 

402 Requested level too high; falling back to lower level (VERS) 
404 Server currently out of service (Connection Setup) 

410 Indicates that the server is not giving any information (HELP) 
411 No hierarchy with that name (GETP, GETA) 

430 Permission denied (GETP, GETA) 

434 Client has no permission to talk to server (Connection Setup) 
510 Syntax error 

511 Internal error (TIME) 

513 Line too long 

519 Unknown command 

610 Regular answer with all requested data (LIST, LSTR) 

611 Regular answer with all requested data (HIER) 

612 Regular answer with all requested data (DATA) 

613 hierarchy data (GETP) 

615 Regular answer with all requested data (GETA) 


11. Data Headers for DATA and HIER Commands (Overview) 


Header Mandatory Use Multiple Description 

Name yes H/N no Name of a hierarchy 
or newsgroup (Start 
of a new data block) 

Status yes H/N no Status of hierarchy 
or newsgroup 

Serial no H/N no Revision of hierarchy 
/newsgroup data 

Followup no N no Group for followup 

Description no H/N no Short description of 
a hierarchy/newsgroup 

Charter no H/N yes Charter-URL 

Netiquette no H/N yes Netiquette-URL 
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FAQ-URL 
Administration rules 
URL 


Control email 
Control newsgroup 
Moderator wildcard 
Submission address 
Moderator’s address 
(email) 

Info-URL 

Language 

Charset 

Encoding 

Type of newsgroup 
Type of hierarchy 
Regional or 
organizational area 
Total length of group 
names 

Component length of 
group names 

Article length 

Date of creation 
Date of removal 
Successor 

Source of data 
Control PGP key 
Moderator's PGP key 


"Multipurpose Internet Mail 
Format of Internet Message 


"Key words for use in RFCs to Indicate 
RFC 2119, March 1997. 


"IETF Policy on Character Sets and 
January 1998. 


FAO no N yes 
Rules no H yes 
Ctl-Send-Adr no H yes 
Ct1-Newsgroup no H yes 
Mod-Wildcard no H no 
Mod-Sub-Adr no N no 
Mod-Adm-Adr no N yes 
Mod-Group-Info no N yes 
Language no H/N yes 
Charset no H/N yes 
Encoding no H/N yes 
Newsgroup-Type no H/N yes 
Hier-Type no H yes 
Area no H yes 
Name-Length no H no 
Comp-Length no H no 
Article-Length no H no 
Date-Create no H/N no 
Date-Delete no H/N no 
Replacement no H/N yes 
Source no H yes 
Ct1-PGP-Key no H yes 
Mod-PGP-Key no N yes 
N: Newsgroup, H: Hierarchy 
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